home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: jbm@jbm.nada.kth.se (Jonas Mvlsd)
- Newsgroups: comp.std.c++
- Subject: Calling X(int) from X()'s init list
- Date: 25 Feb 1996 00:07:28 GMT
- Organization: Royal Institute of Technology, Stockholm, Sweden
- Approved: clamage@eng.sun.com (comp.std.c++)
- Distribution: world
- Message-ID: <4gnush$phg@news.kth.se>
- NNTP-Posting-Host: taumet.eng.sun.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=iso-8859-1
- Content-Transfer-Encoding: quoted-printable
- X-Nntp-Posting-Host: jbm.nada.kth.se
- Originator: clamage@taumet
-
- Why is it not allowed to delegate the initialisation to another=20
- constructor, if that constructor is *the only thing* in the=20
- member initialisation list?=20
-
- It seems to me that in many cases, one could avoid some code=20
- duplication and gain some clarity, at no conceptual or runtime cost.
- The increased clarity would come from folding different constructor
- cases into one case by calling the most general constructor in
- the member initialisation list of the other constructors.
- (I know this is not always clearer, but sometimes it is.)
-
- Is it a case of: "Yes, it is basically a good idea, but it is too=20
- late in the standardisation process. Anyway, we have to draw the
- line somewhere."
-
- Or is it more like: "Of course you should not do it that way, look here..=
- ."
-
-
- A small example to illustrate the technical (not the conceptual)
- detatils of my question:
-
- #include <iostream.h>
-
- class X
- {
- public:
- X (int i) : i_(i) {}
-
- X () : X(34) {} // Not allowed
-
- int i() {return i_;}
-
- private:
- int i_;
- };
-
-
-
- int
- main ()
- {
- X a(55);
- X b;
-
- cout << a.i() << ' ' << b.i() << endl;
- }
- =09
-
- ---
- Jonas M=F6ls=E4, jbm@nada.kth.se
-
- [ To submit articles: Try just posting with your newsreader.
- If that fails, use mailto:std-c++@ncar.ucar.edu
- FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
- Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-